今天來看 Auto DevOps
的最後一個 Feature——Auto Monitoring。這也是基於 GitLab 有串接 K8S,而且有透過 K8S 安裝 Prometheus,Auto DevOps
才有辦法幫你自動產生的功能。
Auto Monitoring 並非是 CI/CD Pipeline 裡面的其中一個 CI Job,它會對應你的 CI/CD Pipeline 有設置哪些 Auto Deploy 及 Environment 而自動產生。
延續我們的範例,Auto DevOps
為我們自動設置了 Staging 與 Production 兩個 Auto Deploy,以及對應的兩個 Environment。
因此在 operations > Metrics
就可以查看兩個 Environment 的 Metrics。
(艦長的沒流量,又只是用 template 建立的範例站,所以一點數據都沒有。XD)
(這是 GitLab 官方文件上的範例圖片,Metrics 實際的面貌會類似上圖這樣。)
Auto DevOps
預設產生的 Metrics 有限,如果你有特別想要查看的 Metric,也可以自行添加。
前往 Settings > Intergrations > Prometheus
即可自行設置,不過一樣貼心小提醒,這是只有熟悉 Prometheus 才懂得如何使用的領域,想要善用這個功能,需要先具備 Prometheus 的知識才行。
今天剩下的篇幅介紹另一個與 Environment 有關的功能,就是當 Project 實際上線之後,另一項需要收集的資訊,那就是 Error Tracking
。Error Tracking 目前市面上也有多家不同的供應商與工具可以選擇,而 GitLab 目前選擇整合的 Error Tracking
則是 Sentry。
同樣在 Operations 內,可以找到 Error Tracking 這個功能。
進入頁面之後 GitLab 就會先提醒你還沒有與 Sentry 串接,接著引導你前往如下面的畫面輸入 Sentry 的相關資料。
Sentry 有提供雲端服務與自架 Server 的方案,兩種都能與 GitLab 整合。
順利串接之後,就可以看見下圖的畫面,但因為我們目前是使用來自 template 的範例站台,還沒有將 Sentry 需要的 SDK 塞進我們的 Source Code,所以目前是收集不到 Error 的。
這邊就借用 GitLab 官方文件的圖片讓大家看一下實際的面貌。
Sentry 還可以有其他的方式與 GitLab 整合,你可登入 Sentry,然後進入 Settings > Intergrations
中設置。
有關 Sentry 的更多內容,不屬於 GitLab 的範圍,因此就留給大家自己去研究了。
今天介紹 Auto DevOps
最後一個功能 Auto Monitoring,這個功能幫助我們收集 Environment 的 Metrics。從這個功能我們可以再次看見 GitLab 的野心,就如我們在前面文章介紹 GitLab Workflow 時提到的,GitLab 持續在網羅各種第三方的服務與工具,並將其與 GitLab 產品生態系結合,打造一條龍的服務,將軟體開發從頭到尾每一個環節都跟 GitLab 綁在一起。
Auto DevOps
體驗到現在,確實有它自動與方便之處,在預設的範圍內就能自動產生堪用的 CI/CD Pipeline,但反之因為它也一口氣引進了大量的新工具,當預設的 CI/CD Pipeline 不符合你的需求或需要客制微調時,就會感受到事情似乎沒有當初想像的那麼美好。只能說天下沒有白吃的午餐,想要役物(工具)而不役於物(工具),該補充的相關知識是少不了的。
今天就先分享到這,鐵人賽倒數中,我們明天見。
自 2021 年 12 月 12 日開始,我就一直想要將原發佈在 iT 邦幫忙的鐵人賽系列文章搬移至 https://gitlab-book.tw 並補充說明文章內容已有過期之處。
因為當初參加 iThome 鐵人賽時,GitLab 仍在 12 版,但如今 GitLab 已更新好幾版了,需要提醒大家注意一下。
本文已完成搬遷